主从、主主、主备的基层逻辑都是数据的同步，而主从则将相关的数据同步机制全涉及，所以数据同步逻辑以解析主从逻辑为主。

mysql主从配置分为三种模式，分别是：

MySQL 复制功能使用三个主线程实现，一个在源服务器上，两个在副本上：

二进制日志转储线程（Binary log dump thread）：当副本连接时，源创建一个线程以将二进制日志内容发送到副本。该线程可以在 SHOW PROCESSLIST 源上的输出中标识为该Binlog Dump线程。 二进制日志转储线程获取源二进制日志上的锁，以读取要发送到副本的每个事件。一旦事件被读取，锁就会被释放，甚至在事件被发送到副本之前。 具备多个从库的主库会为每个链接到主库的从库创建一个Binary log dump thread。

复制 I/O 线程（Replication I/O thread）：当 START SLAVE 在副本服务器上发出语句时，副本会创建一个 I/O 线程，该线程连接到源并要求它发送记录在其二进制日志中的更新。 复制 I/O 线程读取源 Binlog Dump线程发送的更新（参见上一项）并将它们复制到组成 副本中继日志的本地文件中。 该线程的状态：可以通过SHOW SLAVE STATUS语句查询 Slave_IO_running字段的状态值。

复制 SQL 线程（Replication SQL thread）。 副本创建一个 SQL 线程来读取由复制 I/O 线程写入的中继日志并执行其中包含的事务。

主从同步或多数据源同步时，一定要保证多个数据的编码值一致，否则在同步阶段会出现乱码，甚至无法解析的情况。编码设置如下：

主从库均需要设置编码。

主库设置分为：server-id设置、二进制日志设置、同步用户设置等三部。

要将源配置为使用基于二进制日志文件位置的复制，必须确保启用二进制日志记录，并建立唯一的服务ID。并且必须是介于 1 和 (2 32 )-1 之间的正整数。 使用默认服务器 ID 为 0，且拒绝来自副本的任何连接，所以必须保证服务ID各个数据库服务不重复且大于0。配置如下：

binlog日志：数据库每提交一次事务，都会把数据变更，记录到一个二进制文件中，这个二进制文件就叫binlog。需注意：只有写操作才会记录至binlog，只读操作是不会的（如select、show语句）。 binlog的3种格式： 1. statement格式： MySQL 中的复制功能最初是基于 SQL 语句从源到副本的传播，即记录的是实际执行的sql语句。这称为 基于语句的日志记录。

2. row格式： binlog记录的是变化前后的数据（涉及所有列），例如update table_a set col1=value1, col2=value2 ... where col1=condition1 and col2=condition2 ...，这称为 基于行的日志记录。

3. mixed格式：默认选择statement格式，只在需要时改用row格式。这称为 混合日志记录。

为获取前后变化的数据，建议使用 基于行的日志记录，具体配置信息如下：

基于业务情况，我们的数据库中并不是所有的库都需要进行复制同步。所以在开启同步前需要指定哪些库是需要进行同步操作的，即同步过滤。同步过滤有两种方式可以设置，分别是直接指定过滤库以及通过指定库记录二进制日志的方式，两种方式情况如下：

两种方式区别：

配置示例：

每个从库都需要用于读取master库日志的账户信息，前提是它已被授予 REPLICATION SLAVE 特权。虽然可以直接使用root用户，但还是建议单独创建一个独立用户用于从库同步，因为 复制用户名和密码以纯文本形式存储在复制元数据存储库（slave的mysql.slave_master_info表）中。 创建用户示例：如果只是为了同步数据，该账户只需要 REPLICATION SLAVE 权限即可

主库设置好之后，进入从库配置及主从同步机制配置

要将从库设置为与主库通信，则要进行必要的连接信息配置，主要分为三个模块：

主库ip、port和账户信息在上面已经获取或配置好，下面获取主库的二进制日志相关的信息，获取脚本如下：

查询结果如下：

File和Position 稍后在设置副本时需要它们。它们表示副本应该开始处理来自源的新更新的复制坐标。

通过 CHANGE MASTER TO （更多信息请查看官方文档：CHANGE MASTER TO 语句）语句进行设置，登录MySQL数据，执行以下Sql：

此处只使用几个常用参数：

注：如果使用docker部署mysql，则ip为容器的ip，端口为容器内部mysql端口。MASTER_LOG_POS参数一定要与主库查询出来的结果一致，否则无法同步。

无历史数据，全新的主库和从库，上面两步配置完毕后，直接启动复制线程：

执行此过程后，从库将连接到主库并复制自拍摄快照以来在主库上发生的任何更新。

针对已有数据的主库，主从启动之前需要先将主库数据通过快照方式导入从库，以便数据同步。 步骤如下：

1、此过程使用FLUSH TABLES WITH READ LOCK, 阻止 表COMMIT的操作 InnoDB。 2、 FLUSH TABLES语句的客户端保持运行，以便读取锁保持有效。如果退出客户端，锁就会被释放。

2、创建数据快照

3、重新启动源服务器。

4、在从库导入快照数据

5、启动复制线程

6、解锁

可以在不停止源服务器的情况下将另一个副本添加到现有复制配置。方式为通过复制现有副本的数据目录来设置新副本，并为新副本提供不同的 **服务器 ID（由用户指定）**和 服务器 UUID（在启动时生成）。

3、将现有副本的数据目录复制到新副本，包括日志文件和中继日志文件。可以通过使用tar或创建存档来执行此操作 ，或者使用cp或rsyncWinZip等工具执行直接复制 。

4、复制完成后，重新启动现有副本。

5、在新副本上，编辑配置并为新副本提供唯一的服务器 ID（使用 server_id系统变量），源或任何现有副本均未使用该 ID。

6、启动新的副本服务器，指定 --skip-slave-start选项以便复制尚未开始。使用性能模式复制表或问题SHOW SLAVE STATUS来确认新副本与现有副本相比具有正确的设置。还要显示服务器 ID 和服务器 UUID，并验证这些对于新副本是否正确且唯一。

7、通过发出一条 START SLAVE 语句来启动复制线程。

异步复制线程开启后，查看从库的相关状态：

结果中关键字段是：

在主库上进行状态查询的语句有：

主库配置

从库配置

GTID：全局事务标识符 是在源服务器（master）上创建并与提交的每个事务相关联的唯一标识符。这个标识符不仅对于它起源的服务器是唯一的，而且在给定的复制拓扑中的所有服务器中都是唯一的。 针对GTID相关操作可以分为两部分：

GTID 表示为一对坐标，由冒号字符 ( : ) 分隔，如下所示：

GTID = source_id:transaction_id

source_id：标识始发服务器 。通常，源 server_uuid用于此目的。 transaction_id：是一个序列号，由在源上提交事务的顺序确定。其实就是一个自增序列，从1递增。

MySQL 系统表 mysql.gtid_executed 用于保存在 MySQL 服务器上应用的所有事务的分配 GTID，但存储在当前活动的二进制日志文件中的事务除外。

GTID 模式是基于开启二进制服务的基础上进行的，下面操作步骤均已 开启二进制日志为前提。

将mysql服务设置为只读，保证操作期间无数据丢失。

等待所有正在进行的事务提交或回滚。然后，让副本赶上源。在继续之前确保副本已处理所有更新非常重要。

如果是新服务则直接从第三步开始

开启方式增加配置文件：

主库和从库均需设置，设置后重启mysql服务。

在副本上发出一条 CHANGE MASTER TO 语句，包括 MASTER_AUTO_POSITION 在语句中告诉副本源的事务由 GTID 标识的选项。如果除 MASTER_AUTO_POSITION 参数外其它参数均已设置，则可以不进行重复设置。

MASTER_LOG_FILE选项和 选项 都MASTER_LOG_POS不能与 MASTER_AUTO_POSITION=1 一起使用。尝试这样做会导致CHANGE MASTER TO语句失败并出现错误。

启动复制线程：

仅当在 步骤 1 中将服务器配置为只读时，才需要执行以下步骤。要允许服务器再次开始接受更新，请发出以下语句：

因为基于 GTID 的复制依赖于事务，所以在使用 MySQL 时不支持一些原本在 MySQL 中可用的特性。相关限制如下：

主从同步的三种机制分别是异步、半同步、全同步，异步逻辑已经分析完了，下面看下半同步和全同步。先了解下全同步。

全同步（完全同步复制）：当源提交事务时，所有副本也必须在源返回到执行事务的会话之前提交事务。即master每次提交都要等所有副本接收并记录了事件，所有副本都通知master记录成功，master才能提交本次事务。

半同步复制（Semisynchronous Replication）：介于异步复制和完全同步复制之间。源等待直到至少一个副本接收并记录了事件（所需的副本数量是可配置的），然后提交事务。源不等待所有副本确认接收，它只需要来自副本的确认，而不是事件已在副本端完全执行并提交。因此，半同步复制保证如果源崩溃，它已提交的所有事务都已传输到至少一个副本。

源与其副本之间的半同步复制操作如下：

半同步复制是使用插件实现的，因此必须将插件安装到服务器中以使其可用。安装插件后，可以通过与其关联的系统变量来控制它。

服务器插件必须先加载到服务器中才能使用。MySQL 支持在服务器启动和运行时加载插件。还可以在启动时控制已加载插件的激活状态，并在运行时卸载它们。

INSTALL PLUGIN 语句安装的插件：

安装语句：

安装查看

此处查看PLUGINS表信息

结果：

半同步相关的配置项主要使用以下几项：

mysql实例运行时：

如果在运行时在副本上启用半同步复制，则还必须启动复制 I/O 线程（如果它已经在运行，则首先停止它）以使副本连接到源并注册为半同步副本：

实例启动时配置文件配置：

自此半同步配置即完成

MySQL 5.7 支持延迟复制，这样副本服务器故意滞后源至少指定的时间量。默认延迟为 0 秒。设置：

从源接收到的事件直到在源上执行至少 N几秒钟后才会执行。例外情况是格式描述事件或日志文件轮换事件没有延迟，它们只影响 SQL 线程的内部状态。

作用：